IBIS Macromodel Task Group Meeting date: 15 December 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Arpad reminded everyone that meetings on December 22nd and 29th were cancelled, as was the meeting on January 19th because DesignCon and the associated IBIS summit occur that week. - Mike L. asked if there would be an ATM task group report at the DesignCon IBIS summit. Arpad stated that he would draft the report, and someone else could present it if he were unable to attend the summit. -------------------------- Call for patent disclosure: - None. ------------- Review of ARs: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Arpad: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Discussion of language corrections regarding "ground": - Arpad: [Sharing Walter's proposed new paragraph on the screen] - New paragraph: "GND is used in many places in this document as the signal_name of Pins that have Model Name GND. GND in many "buffer example schematics" use this name GND as a signal name such as VCC, VDD, VSS. The string GND in this document shall refer to either a Model Name in the Pin list or a signal name on one or more pins that coincidently also have Model Name GND. GND shall never be interpreted as the reference node in many SPICE simulators that is often called Node 0. Since IBIS defines signal_name as a component Data Book Name, we must assume that all Pins that have Model Name POWER or GND and have the same signal_name are assumed to be connected together on the components board or module. Each buffer can have one or two ground terminals (pdref and/or gcref) that are local nodes of the of the power distribution circuit of Pins that has Model Name GND. [Pin Mapping] is required to determine which signal_name is the local ground nodes of each Buffer." - Bob: My issue is that adding this definition under section 3 goes too far. - It introduces new restrictions that don't exist in IBIS. - It documents rules with respect to keywords, terminals, etc., that aren't defined at that point, and makes forward references to things throughout a 240 page document. - Listing what can be done with "GND" excludes some things that are done now. - For example: While the original intent of IBIS was perhaps that "GND" was a reserved model name, and you could do anything with signal name (we made the suggestion they comply with data book names), it turns out that since ibischk2 you can use "GND" or any of the five other reserved names as [Pin Numbers] if you want. Perhaps this was unintentional, because it was flagged as an error in ibischk1. But, I don't propose changing it. There might be a good reason to call a specific pin GND because it's your ground plane pin. - Radek: So you are saying the pin name can be called GND? - Bob: Yes, or NC or anything and it will pass the parser after ibischk2. - Radek: That's inconsistent with the opening statement that they shouldn't be used for other purposes. - That can be rectified. - Bob: That's why I didn't want to go too far down that path here. - For example, it could also be used as a node name in multilingual. - It would be a 50 page document to enumerate where it can and can't be used. - Making an overly restrictive generalization here opens up trouble. - Arpad: Would it help if we took Walter's paragraph and started by marking it up sentence by sentence as to whether we agree or disagree? - Then if we disagree we have to fix something. - Michael M.: We want to agree on the objective of the paragraph. - Is the object to permanently disassociate "GND" and node 0? - Arpad: I think another motivation on Walter's part is to associate a connectivity meaning with the signal name column. - In other words, signal name is not just a meaningless column containing data book names. There are connectivity assumptions based on the names. - Radek: As far as I recall, we really don't have an association of "GND" with node 0 in the spec, except for one particular statement we can modify. - On the other hand, we have to clearly define what "GND" is. - We need to have the GND node clarified 100%. - Whether it is node "GND" or we call it the "reference node for the I/O port" we have to have it properly defined. - Bob: It's referred to as a model name, and you mention it could be used as a local reference, and not necessarily a global reference such as would exist as node 0 in SPICE. - I think that's as far as we should go in defining it there. - It may be used as a signal name and unless explicitly stated in other areas. - Arpad: From an IC perspective: - GND on an IC can only, at best, be the silicon substrate on the die. - From a Buffer [Model]'s perspective GND at best could be the die substrate. - But it doesn't always have to be, it could be -15V or something else. - The main point is that we really don't have a node 0 type ground on the die. - Bob: In many SPICEs, I think use of "GND" is interpreted as global ground. - Arpad/Radek: That's correct. - Radek: We need to clearly disassociate ourselves from those concepts. - But we still need to have the local ground properly defined. - The signal (input or output), it's a port concept and we need to have two nodes clearly defined. Whether that's the substrate or whatever, is up to the model maker but there must be a way to indicate what it is and to connect to it, including for packages and interconnect models. - Arpad: The IC comment was just the first half of my thought: - From a buffer's perspective on the silicon we are pretty clear, we just have to define what pad the substrate is connected to and how the pad goes out to the pin. - But when it comes to the package and transmission line type models I think the problem gets more complex. In a w-element type environment we have the "reference node", and that reference node is not supposed to be used to model a ground plane or anything carrying non-ideal currents or voltages. But even then the reference node has to be there for numerical purposes. What do we do with that? - Radek: It has to be clearly defined. - We have to make the connections properly. - Arpad: If you have a package model with w-elements that has signal and power and ground traces, a w-element signal terminal will be used for the ground traces as well. But the w-element that carries the ground still has a reference node. Where does that go? - Radek: It goes to whatever is the reference node. If that's local ground it goes to local ground, but we have to know what it is. - If you have two traces and you consider another substrate as the local ground, then you have two transmission lines so the w-element has two traces and six connection pins. Preferably the reference node is the same for both ends because we don't have enough information for different reference nodes. - Discussion: As fodder for a thought experiment, Arpad proposed an example with a buffer containing only power, signal, and ground terminals. Therefore, it has a die with 3 pads and a package with 3 pins. Arpad and Radek had differing opinions on how this would be modeled. Arpad suggested that to get from the board-side of the package to the die-side one would model a 3 conductor w-element, with one conductor each for power, signal and ground. He said that 3 conductor w-element would still have a fourth reference node (or possibly a fifth if a reference node were specified on each end), and that this ideal reference node had nothing to do with the ground pin or ground pad on the die. All 3 conductors would appear in the [Package Model] matrices. Radek countered that if the ground pin provided the local ground then it should be the reference node. He stated Arpad's example would be modeled as two traces (power and signal) with ground serving as the local reference. You would therefore have two ports on each end. Two traces and the local ground or substrate would form two coupled transmission lines. Only the signal and power pins would appear in the [Package Model] matrices. - Arpad [sharing the IBIS-ISS spec's W-element syntax description, and noting: i1 i2 ... in ir o1 o2 ... on or] - Discussion: Arpad referred to his example and suggested it would be modeled with i1 i2 i3 and o1 o2 o3 as the input and output terminals of the 3 conductors (power, signal, ground) and that the ir and or were the ideal reference terminals. Radek again countered with an s-element type port concept and said that the ground conductor would serve as the local reference ir and or, and that it would not itself appear in the [Package Model] matrices. Bob pointed out that it was a "reference conductor" from ir to or, so they couldn't be arbitrary reference nodes at different voltages. Arpad, however, noted that years ago he could not put two different DC sources on the ir and or. But more recently, however, SPICE simulators allowed him to do it. Radek said that in general it did not make much sense to have two separate ir and or nodes, but that it is available, and it is also true that some simulators allow per port references for s-parameters. It's generally best for circuit simulation for ir and or to be the same node. Arpad worried that losses through the ground trace would not be modeled if it's the reference. Radek suggested a losses through the whole loop approach. - Arpad: Isn't this ground reference question central to Walter's paragraph. - Bob: I think Walter's GND statement is just with respect to buffer models. - You need the interconnect spec for transmission lines. - We've dealt with it there, where you bring out a reference line. - Radek: All you have for the [Component] is the external [Pin]s. - Arpad: We're relatively well defined with reference terminals on the die. - What happens though, when you start putting W-elements in the package and on the die? - Radek: In the [Pin Mapping] we really need a local ground entry. - We have pullup_ref, pulldown_ref, etc., even the rarely used ext_ref. - We don't have a local ground specified. That would be the reference we are talking about. - Bob: That's what Walter is proposing, that we define pulldown_ref or gnd_clamp ref as the local ground. - Radek: If there's no conflict with other issues (like -15V). - Arpad: That's why I'm not sure if that solution would work. - Bob: Plus it's confusing, and C_comp to local ground would not resolve the power-aware IBIS issues any better than C_comp to node 0. You need to split up C_comp to distribute it to achieve that. - And as Arpad said, sometimes any terminal can be the local ground. - We've just seen an example on the reflector from a model maker. The input swings from 0 to 3v, but the output swings from 9.9 to -6.6. The output doesn't technically have a local ground terminal. All of the numbers in the model are multiples of 3.3v. It's got an internal voltage multiplier as its reference. The reference terminals aren't even attached externally. - Radek: Additionally, if you have a pseudo-differential buffer consisting of two single ended buffers, how do you connect them? - We simply need those nodes. - Bob: In our early days the thinking was that global node 0 was as good as any. - Radek: But the idea is that node was there from the beginning. It was just assumed to be node zero. Now we want to call it "GND" and say it is not necessarily node 0, but the node was there from the beginning. - Discussion: Arpad asked if Randy would be willing to weigh in on the topic since Micron develops high quality package models and IBIS models in general. Randy mentioned that Curtis had recently been asking him similar reference related questions about package models. Randy said that when simulating a package substrate, their package modeling tools require the definition of a ground reference for that simulation. In the 2.5 or 3D field solver one might define that at infinity, but they usually define a reference plane by defining a metal structure some distance below the package substrate. When that package is solved, ground traces or planes within the package are defined as though they are signals, not used as any sort of reference. When you get the data out of the package simulator you have capacitance not only from a particular signal to your ground trace, but also from that signal to your external reference, which is more like node zero. Randy acknowledged that when many tools output a SPICE sub circuit for the package model, they have a ground node for the actual ground trace but end up using node 0 inside the sub circuit to serve as the external reference. He said that how to deal with that and avoid the implicit connection to node zero was on open question for us. Radek expressed his concern that without giving the IBIS user more information about the external reference node they had insufficient information, and we were left with no choice but to use node 0. He suggested that one of the actual ground traces should be defined as the reference. Arpad asked whether the capacitances with respect to the external reference node were significant in value or perhaps negligible. Randy said that it depended upon the structure of the package and that, for example, a structure with a single layer and no ground plane might show significant coupling between a signal and the external reference layer. Arpad said that with a far away reference he would expect the terms to be very small, but it sounded like Randy's simulations needed to use a closer reference. Randy said that they tend to model their packages using a reference plane just below the solder balls because that's the closest description of the way the package is actually attached to a real circuit board. He said this placement tended to give them simulations with the best correlation with measured data. - Arpad: We've talked a lot, but I'm not sure if we are making progress. - Discussion: Mike L. noted that we started with the goal of going over Walter's paragraph, and then the question was raised about the whether we all agreed on the objective of the paragraph. Mike said that he felt Walter's initial statement on "GND" read more like a style guide, or upfront warning to the user that they might encounter "GND" as a model name or a signal name. He said that the spec actually used GND as a signal name in relatively few places, and that we might be able to remove those uses from the spec by simply renaming things where GND had been used as a signal name. He said this would eliminate confusion in the spec and obviate the need for Walter's statement. Arpad and Bob objected to this idea. Neither felt that it was necessary to alter the way GND had been used in the spec. Bob felt that since it was legal to have GND as a signal name, perhaps if a data book name really was GND, we should not attempt to remove such usage from the spec. Arpad felt that we could simply clarify the meaning in each instance where GND was used in the spec. Radek pointed out that the interconnect proposal went in that direction and designated whether something was a pin name, signal name, etc. - Mike L: [sharing IBIS 6.1, Section 6.1, page 33, paragraph 2] - Discussion: Mike L. pointed out that this paragraph, which describes how the capacitors related to C_comp_xxx values are connected, uses GND in the context of a ground node. He felt this hadn't been properly defined. Bob agreed and said that it should be "local ground reference" in a rewrite. Michael M. was even more critical of the last sentence. He said we already overloaded the four [Pullup Reference], [Pulldown Reference], [POWER Clam Reference], [GND Clamp Reference] keywords in the sense that they could be values or reference nodes, and pointed out that this paragraph strongly implied that [Voltage Range] itself was some sort of power rail instead of just a value representing the potential difference between two particular nodes. Everyone agreed that this paragraph will need to be rewritten. - Arpad: It seems that Walter's proposal was an attempt to define a general rule at the outset that could allow us to resolve many issues with one statement. - I'm beginning to wonder if it is going to work that way. - Perhaps we would be better off to start reading the document sentence by sentence and hashing out the details for each necessary change. Then, as we are doing that, if we run into something that could be generalized up front we can add an upfront statement. - Right now it seems that we've spent two meetings trying to tackle the generalized concept and still have confusion and or disagreement. - Mike L.: I was thinking the same thing. - Arpad: With that let's close the meeting today. - Thank you all for the good work in 2015. Happy Holidays and Happy New Year. ------------- Next meeting: 05 January 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives